For the past 2 months, the night I install updates on the Exchange 2013 servers, after the second server is updated I cannot move the databases to their normal servers (we have the servers in an active - active setup with half of the databases on each).

When I try to move them using the ECP console it fails, the error it reports is:

error
databasename
An Active Manager operation failed. Error: The database action failed. Error: An error occurred while trying to validate the specified database copy for possible activation. Error:


        servername:
        Database copy 'databasename' on server 'servername' has a total (copy plus replay) queue length of 9223372036853793063 logs, which is higher than the maximum allowed queue length of 400. If you need to activate this database copy, you can use the Move-ActiveMailboxDatabase cmdlet with the -SkipLagChecks and -MountDialOverride parameters to forcibly activate the database copy. If the database does not automatically mount after running Move-ActiveMailboxDatabase successfully, use the Mount-Database cmdlet to mount the database.
         [Database: databasename, Server: servername.domain.com]

I found multiple reports of this in Exchange 2010 but nothing for 2013. I tried the powershell commands used in 2010 to force a move, but i get a database in unknown status not active on either server.

Last month I reseeded one database and it suddenly changed the CQL to 0 for all other databases and let me move them.

Any ideas what is causing this and how I fix it without spending hours waiting for a reseed to finish?

So, I found that suspending one of the databases takes about 45 minutes, then suddwnly all the CQLs drop to zero though the index state is unknown so activating the passive copy is still not possible.

20 minutes later, the index is healthy and I can activate as normal.

Problem solved but root cause still unknown, any suggestions would be gratefully received

When the copy queue length is that high what are the status of the database copies? Are they healthy? Can you run Test-ReplicationHealth when this is happening?

Also, You might need to run Get-MailboxDatabaseCopyStatus <dbcopy> | fl 

If the copy is failed that shoudl tell you why its failed.

Hi,

According to the error message, the queue length should be 0 or close to that.  It looks like database isn't replicating to the server holding its copy.
Please run Get-MailboxDatabaseCopyStatus and Test-ReplicationHealth as Hite mentioned to get more details about DAG copy and replication.

Heres an similar thread about your issue, for your reference:
https://social.technet.microsoft.com/Forums/exchange/en-US/d38bc1df-c037-4e11-bd4b-5e63923f6f9a/exchange-database-copy-queue-length-number-increased-to-9223372036829610137?forum=exchangesvradmin

Thanks

The 9223372036853793063 is n auto defense mechanism introduced in Exchange 2010 to ret to prevent corrupt copies of databases. However, as I said in my original question, this only happens after I move the databases onto a single server, update and reboot the now passive server and try to move them back so I can update the second server. ALL databases report the same issue, not just one. The databases status is listed as unknown, the CAP is 9223372036853793063 and the index shows as healthy (how can it be healthy when the database status is unknown?)

If I try to suspend any of the databases using ECP it does nothing, using the command shell it reports no issues but the status does not change. Using command shell to force a move says it has worked but then both copies of the database are inactive and I have to reactivate the copy being used before I tried to force it. Around 45 minutes after trying to suspend the database copy it eventually changes to suspend and, as if by magic, ALL databases suddenly have a CQL of 0 and I am able to move them.

This started last month, at that time I decided to reseed one of the databases to see if it resolved the issue, I was concentrating on that process, it needs to be suspended to reseed so I was trying to find a way to suspend it, and thought the reseed fixed the issue as all CALs dropped tozero, however itnow looks like the actual execution of the suspend command is what cures the problem.

What I want to know is why is this happening when I install updates and patches on the servers? It ran fine, no issues, for 10 months but now does this every time I install updates.

The database status is listed as unknown, if it was failed I'd do a reseed to create a new copy.

Maybe there is an issue with you storage device.  Can you create a new DB on a different device and try the same thing?